This invention relates generally to a method and apparatus for managing generalized traffic flows. More specifically, this invention relates to a method and apparatus for managing the flow of asynchronous, synchronous, and isochronous information over a common information carrying medium.
The past decade has brought the convergence of telephony and data communications systems. Prior to this period, conventional telephony systems concentrated on establishing voice links between persons, while conventional data communication systems were limited to the sharing of information between computer networks. With the advent of personal computers and other personal electronic devices such as wireless telephones and pagers, the information exchanged between persons today has become a combination of voice, data, and video, or so-called multimedia information.
Today's information service providers (ISPs) are developing solutions to deliver multimedia information, including Internet data services, telephone services, and TV services, directly to customers' premises. It is preferred that the data for these various multimedia services be carried to customer premises over the same medium, such as a TV coaxial cable, telephone cable, or the over air (or wireless). Thus, modern communication channels must be able to combine all types of multimedia traffic flow onto the same carrier.
The various multimedia services typically employ different information protocols, which in turn require that the data transmitted using these protocols exhibit certain characteristics. A problem associated with integrating these services for transmission over the same medium is that while each of the services may impose varying limitations on the degree of data integrity, the applications using these various services may require different levels of data integrity. These application-specific requirements may impose overall lesser or greater constraints on the data integrity than do the services themselves.
For example, synchronous services typically do not allow for any delay variations to occur in the data delivery. The synchronous information delivery is often governed by strict timing requirements. Yet, the types of applications that often require synchronous services, e.g, voice communication, can nevertheless tolerate a certain amount of data loss. Thus, if voice data cannot be delivered according to the timing regime of the synchronous service carrying the data, the data may occasionally be discarded without adversely affecting the overall quality of the voice transmission.
The timing constraints associated with isochronous services are somewhat more relaxed than those associated with synchronous services. For example, as long as the information carried by the isochronous services is delivered within a certain time window, the performance of the service is deemed acceptable. The timing windows themselves, however, are strictly time-bounded. Even though the timing constraints are somewhat more relaxed, certain applications using isochronous services, e.g., video transmission, may actually be more sensitive to data loss than applications using the more rigid synchronous services, e.g., voice communication. Nevertheless, it may be necessary to accept some degree of data loss in these data sensitive applications in order to avoid exceeding the time window borders which may have an overall greater detrimental effect on the isochronous transmission.
Finally, with asynchronous services, the transmitted data typically need not meet any strict timing requirements. In contrast, however, the applications that often use asynchronous services, e.g., file transfer and other types of pure data delivery, require 100% data integrity. That is, no errors or loss of data are allowed in the received transmission.
When each of these different types of multimedia services are integrated for transmission over a shared medium, the traffic flows on this shared medium can be divided into three categories: synchronous traffic, asynchronous traffic, and isochronous traffic. Although there exists a need for a technique for combining and managing these different traffic flows on a common shared medium, techniques have been developed to support each of these different traffic flow types individually on dedicated media.
For example, Asynchronous Transfer Mode, or ATM, has been developed to support wired traffic flows of multimedia information. In ATM systems, the traffic flows are transported in short packets. Packets from the different sources in an ATM network are combined onto a shared medium which uses time slots to carry the individual packets of data.
Other examples include wireless systems based on either Time Division Multiple Access (TDMA) technology, including GSM, D-AMPS, or DECT systems, or wireless systems based on general time slotting techniques, such as Bluetooth™ or HIPERLAN/2. These wireless based systems divide the time axis into time slots which are used to carry information over the shared medium. Several communication channels are combined onto the shared medium by placing each of the channels into a different time slot. These time-slotted systems are particularly suited to support the transfer of multimedia traffic. Special characteristics could be assigned to the different time slots such that the different traffic flows could be supported, even when these time slots belong to the same shared medium.
As discussed above, the three categories of traffic flows differ by the timing constraints placed on the data carried in a respective flow. Synchronous traffic, for example, is characterized by a strictly time-bounded, continuous, real-time flow of information. A typical example of synchronous traffic is a voice stream produced by a speaking user. The synchronous flow does not allow for any delay variations to occur in the data transmission. However, because a synchronous flow is quickly outdated (i.e., the value of information to the recipient has only a limited life span), a certain amount of errors in the traffic flow can be tolerated, as new information is constantly entering the traffic flow. Thus, if errors occur in the synchronous flow, they may be corrected, e.g., by using forward-error-correcting (FEC) parity bits added to the information stream. Alternatively, if no FEC is applied to the stream, other redundant information in the stream may be used. However, in conventional synchronous flows, the recipient of data cannot request a retransmission of that data to correct errors, since this would introduce delay variations which cannot be tolerated in a synchronous flow.
In contrast, asynchronous traffic is not time-bounded. The time allowed to transfer asynchronous information to the recipient is unlimited. A common example of data in an asynchronous traffic flow is the transfer of an email message or of a file. Typically, the recipient is not continuously waiting for this information, but instead is informed when the message has arrived. Unlike synchronous traffic, the information in an asynchronous flow is not contained in a stream, but rather is transferred in blocks of data, e.g., a piece of text, or a photograph. Although errors in these data blocks typically cannot be tolerated, because delay variations present no problems in asynchronous flow, the recipient can check the data for errors and request a retransmission of data from the sender for those data blocks that contain errors.
Finally, in between the pure synchronous and pure asynchronous traffic flows, is the isochronous traffic flow, where a sender has a limited opportunity to retransmit erroneous data blocks. Like the data in a synchronous flow, information contained in an isochronous flow has a certain lifetime. During a limited time window, a data block can be re-transmitted as often as desired (provided channel capacity is available). If, however, the limited lifetime has expired, the data block must be discarded, and the next block is considered, again for a limited lifetime.
From this, it can be recognized that both synchronous and asynchronous traffic flows are special forms of the isochronous traffic flow. For example, as the lifetime of a data block is reduced (i.e., a lesser number of re-transmissions being possible), the traffic flow will resemble more and more a synchronous traffic flow. In the extreme, when the lifetime is reduced to the point where a data block can only be sent once (i.e., no re-transmissions are possible), the traffic becomes synchronous. At the other extreme, as the lifetime of a data block increases, the number of re-transmissions increases and in the extreme, the traffic flow resembles an asynchronous traffic flow. Thus, by controlling the lifetime of the data blocks, the information sender can dynamically change the characteristics of an isochronous traffic flow to resemble either a synchronous flow or an asynchronous flow.
Numerous conventional automatic retransmission query (ARQ) schemes have been developed as described in the text “Data Networks” by Bertsekas and Gallager, Prentice-Hall, Inc., 1992 (ISBN 0-13201674-5). These conventional schemes typically operate by fragmenting the traffic flow into segments; each segment being assigned a respective sequence number. Using the sequence numbers, the recipient can then re-order the various segments that have arrived, and can detect those segments that may be missing from the transmission (e.g., resulting from errors on the channel), and which require re-transmissions.
ARQ schemes are commonly used for addressing data integrity issues in asynchronous services. With asynchronous services, re-transmissions may be carried out whenever a segment of data is not received correctly. ARQ schemes may also be used in conjunction with isochronous services. With these services, the segments of a data block, or message, having errors may be re-transmitted as long as the lifetime associated with the data block or message has not expired. When the time window associated with a received segment has passed, however, and the segment still requires to be re-transmitted as a result of errors in the data, the sender must abort the retransmission and continue the data reception in the next window. Therefore, it is desirable to implement ARQ schemes that can be separately applied for any given time window.
An issue that must be addressed when applying ARQ schemes to the various traffic flow types concerns the ARQ initialization process. For an asynchronous service, there can be an initialization process at the beginning of the session. In this case, both the sender and recipient of the asynchronous flow are informed of the initial conditions prior to information transmission. For isochronous services, however, the initialization must be applied at the start of each new window. Indeed, the ARQ scheme initialization process becomes of greater and greater importance as the message lifetime decreases. Therefore, an efficient method of initialization of the ARQ scheme, capable of functioning within these varying traffic flows is required.
As described earlier, it is recognized that the asynchronous, isochronous, and synchronous traffic flows can be interrelated using the concept of a lifetime (or existence window) associated the data carried in these traffic flows. The respective services using these various traffic flows may thus be generalized using the segment lifetime as a parameter in the ARQ scheme. For asynchronous services, the lifetime is infinite, and the number of available re-transmissions is unlimited. With isochronous services, however, the lifetime is fixed and the number of available re-transmissions is restricted, accordingly. Finally, for synchronous services, the lifetime is zero and the number of available re-transmissions is zero.